|
|
|
|
|
|
|
Public Sub updateOneRecord(Optional argClientObject _
As Object) |
|
|
|
|
|
|
|
|
addNewRecord facilitates the adding of records to the underlying data source. CancelTrans cancels a transaction. In the case of Ado, you can cancel a batch operation or update operation. pChangedByCode and pDataChanged are boolean flags that alert the subsystem in the application that either the application (pChangedByCode) or the user (pDataChange) changed a data-aware field. |
|
|
|
|
|
|
|
|
pBookMark is a bookmark for the resultset. DBColumn is a reference to a particular column in the resultset. PEditFlag prepares the environment for editing a record in the resultset. pAddNewFlag, in conjunction with addNewRecord, prepares the environment for adding a new record to the underlying database via the resultset. The methods getFirstRec, getLastRec, getNextRec, and getPreviousRec are used to navigate through the resultset. They are typically invoked by the clickedFirstLastRecord methods of CDatabaseForm. getRecordCount obtains the numeric total of all the records in the resultset. openDBResultset opens the resultset against the connection object referenced by the argument, argDBConnection. The argument argSQL is the SQL statement used to open the resultset. The property pCurrentSQL holds the value of argSQL. The properties pBOF and pEOF specify whether the resultset is at the beginning or end of the set. |
|
|
|
|
|
|
|
|
The method prepareForChange prepares the environment for a change to data fields by the application code. The property pResultset is a reference to the resultset object. pSQLTimeout establishes the time-out value that determines how long the resultset should take in obtaining records. RSFields contains a reference to the columns in the resultset. The method startEditMode prepares the environment for editing a record, working in conjunction with pEditFlag. Finally, updateOneRecord prepares the environment for updating a single record to the underlying database. You can create a corresponding method to update a batch of records. |
|
|
|
|
|
|
|
|
Practical Guidelines for Implementing Database Access in Code |
|
|
|
|
|
|
|
|
Where possible, you should start using ActiveX Data Objects in your database applications. ADO will become the standard mechanism for Visual Basic, particularly because of its strong Internet capabilities. RDO will still remain a dominant force for some time because it works so well with the ODBC API. However, ADO will catch up with it soon. Moreover, it's helpful if you compile this subsystem into its own ActiveX component because it can quickly become large and complex. Debugging it with subsystems from other parts of the application in one project will prove to be a constant source of frustration because you'll likely feel overwhelmed by all the many classes and lines of code. A |
|
|
|
|
|